home *** CD-ROM | disk | FTP | other *** search
/ Fun Clips 1 / Fun Clips Amiga.iso / viewtek / anim7.doc next >
Text File  |  1992-12-04  |  29KB  |  602 lines

  1.  
  2.  
  3.                               A N I M
  4.                   An IFF Format For CEL Animations
  5.  
  6.                     Revision date:  4 May 1988
  7.  
  8.                      prepared by:
  9.                           SPARTA Inc.
  10.                           23041 de la Carlota
  11.                           Laguna Hills, Calif 92653
  12.                           (714) 768-8161
  13.                           contact: Gary Bonham
  14.  
  15.                      also by:
  16.                           Aegis Development Co.
  17.                           2115 Pico Blvd.
  18.                           Santa Monica, Calif 90405
  19.                           213) 392-9972
  20.  
  21.              Anim7 Appendix (july 92) by:
  22.               Wolfgang Hofer
  23.               A-2722 Winzendorf
  24.               Wr. Neustaedterstr. 140
  25.  
  26. 1.0 Introduction
  27.  
  28.    The ANIM IFF format was developed at Sparta originally for the
  29.    production of animated video sequences on the Amiga computer.  The
  30.    intent was to be able to store, and play back, sequences of frames
  31.    and to minimize both the storage space on disk (through compression)
  32.    and playback time (through efficient de-compression algorithms).
  33.    It was desired to maintain maximum compatibility with existing
  34.    IFF formats and to be able to display the initial frame as a normal
  35.    still IFF picture.
  36.  
  37.    Several compression schemes have been introduced in the ANIM format.
  38.    Most of these are strictly of historical interest as the only one
  39.    currently being placed in new code is the vertical run length
  40.    encoded byte encoding developed by Jim Kent.
  41.  
  42.    1.1 ANIM Format Overview
  43.  
  44.       The general philosophy of ANIMs is to present the initial frame
  45.       as a normal, run-length-encoded, IFF picture.  Subsequent
  46.       frames are then described by listing only their differences
  47.       from a previous frame.  Normally, the "previous" frame is two
  48.       frames back as that is the frame remaining in the hidden
  49.       screen buffer when double-buffering is used.  To better
  50.       understand this, suppose one has two screens, called A and B,
  51.       and the ability to instantly switch the display from one to
  52.       the other.  The normal playback mode is to load the initial
  53.       frame into A and duplicate it into B.  Then frame A is displayed
  54.       on the screen.  Then the differences for frame 2 are used to
  55.       alter screen B and it is displayed.  Then the differences for
  56.       frame 3 are used to alter screen A and it is displayed, and so
  57.       on.  Note that frame 2 is stored as differences from frame 1,
  58.       but all other frames are stored as differences from two frames
  59.       back.
  60.  
  61.       ANIM is an IFF FORM and its basic format is as follows (this
  62.       assumes the reader has a basic understanding of IFF format
  63.       files):
  64.                       FORM ANIM
  65.                       . FORM ILBM         first frame
  66.                       . . BMHD                normal type IFF data
  67.                       . . ANHD                optional animation header
  68.                                               chunk for timing of 1st frame.
  69.                       . . CMAP
  70.                       . . BODY
  71.                       . FORM ILBM         frame 2
  72.                       . . ANHD                animation header chunk
  73.                       . . DLTA                delta mode data
  74.                       . FORM ILBM         frame 3
  75.                       . . ANHD
  76.                       . . DLTA
  77.                            ...
  78.  
  79.       The initial FORM ILBM can contain all the normal ILBM chunks,
  80.       such as CRNG, etc.  The BODY will normally be a standard
  81.       run-length-encoded data chunk (but may be any other legal
  82.       compression mode as indicated by the BMHD).  If desired, an ANHD
  83.       chunk can appear here to provide timing data for the first
  84.       frame.  If it is here, the operation field should be =0.
  85.  
  86.       The subsequent FORMs ILBM contain an ANHD, instead of a BMHD,
  87.       which duplicates some of BMHD and has additional parameters
  88.       pertaining to the animation frame.  The DLTA chunk contains
  89.       the data for the delta compression modes.  If
  90.       the older XOR compression mode is used, then a BODY chunk
  91.       will be here.  In addition, other chunks may be placed in each
  92.       of these as deemed necessary (and as code is placed in player
  93.       programs to utilize them).  A good example would be CMAP chunks
  94.       to alter the color palette.  A basic assumption in ANIMs is
  95.       that the size of the bitmap, and the display mode (e.g. HAM)
  96.       will not change through the animation.  Take care when playing
  97.       an ANIM that if a CMAP occurs with a frame, then the change must
  98.       be applied to both buffers.
  99.  
  100.       Note that the DLTA chunks are not interleaved bitmap representations,
  101.       thus the use of the ILBM form is inappropriate for these frames.
  102.       However, this inconsistency was not noted until there were a number
  103.       of commercial products either released or close to release which
  104.       generated/played this format.  Therefore, this is probably an
  105.       inconsistency which will have to stay with us.
  106.  
  107.    1.2 Recording ANIMs
  108.  
  109.       To record an ANIM will require three bitmaps - one for
  110.       creation of the next frame, and two more for a "history" of the
  111.       previous two frames for performing the compression calculations
  112.       (e.g. the delta mode calculations).
  113.  
  114.       There are five frame-to-frame compression methods currently
  115.       defined.  The first three are mainly for historical interest.
  116.       The product Aegis VideoScape 3D utilizes the third method in
  117.       version 1.0, but switched to method 5 on 2.0.  This is
  118.       the only instance known of a commercial product generating
  119.       ANIMs of any of the first three methods.  The fourth method
  120.       is a general short or long word compression scheme which has
  121.       several options including whether the compression is horizontal
  122.       or vertical, and whether or not it is XOR format.  This offers
  123.       a choice to the user for the optimization of file size and/or
  124.       playback speed.  The fifth method is the byte vertical run length
  125.       encoding as designed by Jim Kent.  Do not confuse
  126.       this with Jim's RIFF file format which is different than ANIM.
  127.       Here we utilized his compression/decompression routines within the
  128.       ANIM file structure.
  129.  
  130.       The following paragraphs give a general outline of each of the
  131.       methods of compression currently included in this spec.
  132.  
  133.       1.2.1 XOR mode
  134.  
  135.          This mode is the original and is included here for historical
  136.          interest.  In general, the delta modes are far superior.
  137.          The creation of XOR mode is quite simple.  One simply
  138.          performs an exclusive-or (XOR) between all corresponding
  139.          bytes of the new frame and two frames back.  This results
  140.          in a new bitmap with 0 bits wherever the two frames were
  141.          identical, and 1 bits where they are different.  Then this
  142.          new bitmap is saved using run-length-encoding.  A major
  143.          obstacle of this mode is in the time consumed in performing
  144.          the XOR upon reconstructing the image.
  145.  
  146.       1.2.2 Long Delta mode
  147.  
  148.          This mode stores the actual new frame long-words which are
  149.          different, along with the offset in the bitmap.  The
  150.          exact format is shown and discussed in section 2 below.
  151.          Each plane is handled separately, with no data being saved
  152.          if no changes take place in a given plane.  Strings of
  153.          2 or more long-words in a row which change can be run
  154.          together so offsets do not have to be saved for each one.
  155.  
  156.          Constructing this data chunk usually consists of having
  157.          a buffer to hold the data, and calculating the data as
  158.          one compares the new frame, long-word by long-word, with
  159.          two frames back.
  160.  
  161.       1.2.3 Short Delta mode
  162.  
  163.          This mode is identical to the Long Delta mode except that
  164.          short-words are saved instead of long-words.  In most
  165.          instances, this mode results in a smaller DLTA chunk.
  166.          The Long Delta mode is mainly of interest in improving
  167.          the playback speed when used on a 32-bit 68020 Turbo Amiga.
  168.  
  169.       1.2.4 General Delta mode
  170.  
  171.          The above two delta compression modes were hastily put together.
  172.          This mode was an attempt to provide a well-thought-out delta
  173.          compression scheme.  Options provide for both short and long
  174.          word compression, either vertical or horizontal compression,
  175.          XOR mode (which permits reverse playback), etc.  About the time
  176.          this was being finalized, the fifth mode, below, was developed
  177.          by Jim Kent.  In practice the short-vertical-run-length-encoded
  178.          deltas in this mode play back faster than the fifth mode (which
  179.          is in essence a byte-vertical-run-length-encoded delta mode) but
  180.          does not compress as well - especially for very noisy data such
  181.          as digitized images.  In most cases, playback speed not being
  182.          terrifically slower, the better compression (sometimes 2x) is
  183.          preferable due to limited storage media in most machines.
  184.  
  185.          Details on this method are contained in section 2.2.2 below.
  186.  
  187.       1.2.5 Byte Vertical Compression
  188.  
  189.          This method does not offer the many options that method 4 offers,
  190.          but is very successful at producing decent compression even for
  191.          very noisy data such as digitized images.  The method was devised
  192.          by Jim Kent and is utilized in his RIFF file format which is
  193.          different than the ANIM format.  The description of this method
  194.          in this document is taken from Jim's writings.  Further, he has
  195.          released both compression and decompression code to public domain.
  196.  
  197.          Details on this method are contained in section 2.2.3 below.
  198.  
  199.    1.3 Playing ANIMs
  200.  
  201.       Playback of ANIMs will usually require two buffers, as mentioned
  202.       above, and double-buffering between them.  The frame data from
  203.       the ANIM file is used to modify the hidden frame to the next
  204.       frame to be shown.  When using the XOR mode, the usual run-
  205.       length-decoding routine can be easily modified to do the
  206.       exclusive-or operation required.  Note that runs of zero bytes,
  207.       which will be very common, can be ignored, as an exclusive or
  208.       of any byte value to a byte of zero will not alter the original
  209.       byte value.
  210.  
  211.       The general procedure, for all compression techniques, is to first
  212.       decode the initial ILBM picture into the hidden buffer and double-
  213.       buffer it into view.  Then this picture is copied to the other (now
  214.       hidden) buffer.  At this point each frame is displayed with the
  215.       same procedure.  The next frame is formed in the hidden buffer by
  216.       applying the DLTA data (or the XOR data from the BODY chunk in the
  217.       case of the first XOR method) and the new frame is double-buffered
  218.       into view.  This process continues to the end of the file.
  219.  
  220.       A master colormap should be kept for the entire ANIM which would
  221.       be initially set from the CMAP chunk in the initial ILBM.  This
  222.       colormap should be used for each frame.  If a CMAP chunk appears
  223.       in one of the frames, then this master colormap is updated and the
  224.       new colormap applies to all frames until the occurrance of another
  225.       CMAP chunk.
  226.  
  227.       Looping ANIMs may be constructed by simply making the last two frames
  228.       identical to the first two.  Since the first two frames are special
  229.       cases (the first being a normal ILBM and the second being a delta from
  230.       the first) one can continually loop the anim by repeating from frame
  231.       three.  In this case the delta for creating frame three will modify
  232.       the next to the last frame which is in the hidden buffer (which is
  233.       identical to the first frame), and the delta for creating frame four
  234.       will modify the last frame which is identical to the second frame.
  235.  
  236.       Multi-File ANIMs are also supported so long as the first two frames
  237.       of a subsequent file are identical to the last two frames of the
  238.       preceeding file.  Upon reading subsequent files, the ILBMs for the
  239.       first two frames are simply ignored, and the remaining frames are
  240.       simply appended to the preceeding frames.  This permits splitting
  241.       ANIMs across multiple floppies and also permits playing each section
  242.       independently and/or editing it independent of the rest of the ANIM.
  243.  
  244.       Timing of ANIM playback is easily achieved using the vertical blank
  245.       interrupt of the Amiga.  There is an example of setting up such
  246.       a timer in the ROM Kernel Manual.  Be sure to remember the timer
  247.       value when a frame is flipped up, so the next frame can be flipped
  248.       up relative to that time.  This will make the playback independent
  249.       of how long it takes to decompress a frame (so long as there is enough
  250.       time between frames to accomplish this decompression).
  251.  
  252. 2.0 Chunk Formats
  253.    2.1 ANHD Chunk
  254.       The ANHD chunk consists of the following data structure:
  255.  
  256.            UBYTE operation  The compression method:
  257.                             =0 set directly (normal ILBM BODY),
  258.                             =1 XOR ILBM mode,
  259.                             =2 Long Delta mode,
  260.                             =3 Short Delta mode,
  261.                             =4 Generalized short/long Delta mode,
  262.                 =5 Byte Vertical Delta mode
  263.                 =7 short/long Vertical Delta mode
  264.                             =74 (ascii 'J') reserved for Eric Graham's
  265.                                compression technique (details to be
  266.                                released later).
  267.  
  268.            UBYTE mask      (XOR mode only - plane mask where each
  269.                             bit is set =1 if there is data and =0
  270.                             if not.)
  271.            UWORD w,h       (XOR mode only - width and height of the
  272.                             area represented by the BODY to eliminate
  273.                             unnecessary un-changed data)
  274.            WORD  x,y       (XOR mode only - position of rectangular
  275.                             area representd by the BODY)
  276.            ULONG abstime   (currently unused - timing for a frame
  277.                             relative to the time the first frame
  278.                             was displayed - in jiffies (1/60 sec))
  279.            ULONG reltime   (timing for frame relative to time
  280.                             previous frame was displayed - in
  281.                             jiffies (1/60 sec))
  282.            UBYTE interleave (unused so far - indicates how may frames
  283.                              back this data is to modify.  =0 defaults
  284.                              to indicate two frames back (for double
  285.                              buffering). =n indicates n frames back.
  286.                              The main intent here is to allow values
  287.                              of =1 for special applications where
  288.                              frame data would modify the immediately
  289.                              previous frame)
  290.            UBYTE pad0        Pad byte, not used at present.
  291.            ULONG bits        32 option bits used by options=4 and 5.
  292.                              At present only 6 are identified, but the
  293.                              rest are set =0 so they can be used to
  294.                              implement future ideas.  These are defined
  295.                              for option 4 only at this point.  It is
  296.                              recommended that all bits be set =0 for
  297.                              option 5 and that any bit settings
  298.                              used in the future (such as for XOR mode)
  299.                              be compatible with the option 4
  300.                              bit settings.   Player code should check
  301.                              undefined bits in options 4 and 5 to assure
  302.                              they are zero.
  303.  
  304.                              The six bits for current use are:
  305.  
  306.                              bit #              set =0               set =1
  307.                              ===============================================
  308.                              0              short data           long data
  309.                              1                 set                  XOR
  310.                              2             separate info        one info list
  311.                                            for each plane       for all planes
  312.                              3               not RLC        RLC (run length coded)
  313.                              4              horizontal           vertical
  314.                              5           short info offsets   long info offsets
  315.  
  316.            UBYTE pad[16]     This is a pad for future use for future
  317.                              compression modes.
  318.  
  319.    2.2 DLTA Chunk
  320.  
  321.       This chunk is the basic data chunk used to hold delta compression
  322.       data.  The format of the data will be dependent upon the exact
  323.       compression format selected.  At present there are two basic
  324.       formats for the overall structure of this chunk.
  325.  
  326.       2.2.1 Format for methods 2 & 3
  327.  
  328.          This chunk is a basic data chunk used to hold the delta
  329.          compression data.  The minimum size of this chunk is 32 bytes
  330.          as the first 8 long-words are byte pointers into the chunk for
  331.          the data for each of up to 8 bitplanes.  The pointer for the
  332.          plane data starting immediately following these 8 pointers will
  333.          have a value of 32 as the data starts in the 33-rd byte of the
  334.          chunk (index value of 32 due to zero-base indexing).
  335.  
  336.          The data for a given plane consists of groups of data words.  In
  337.          Long Delta mode, these groups consist of both short and long
  338.          words - short words for offsets and numbers, and long words for
  339.          the actual data.  In Short Delta mode, the groups are identical
  340.          except data words are also shorts so all data is short words.
  341.          Each group consists of a starting word which is an offset.  If
  342.          the offset is positive then it indicates the increment in long
  343.          or short words (whichever is appropriate) through the bitplane.
  344.          In other words, if you were reconstructing the plane, you would
  345.          start a pointer (to shorts or longs depending on the mode) to
  346.          point to the first word of the bitplane.  Then the offset would
  347.          be added to it and the following data word would be placed at
  348.          that position.  Then the next offset would be added to the
  349.          pointer and the following data word would be placed at that
  350.          position.  And so on...  The data terminates with an offset
  351.          equal to 0xFFFF.
  352.  
  353.          A second interpretation is given if the offset is negative.  In
  354.          that case, the absolute value is the offset+2.  Then the
  355.          following short-word indicates the number of data words that
  356.          follow.  Following that is the indicated number of contiguous
  357.          data words (longs or shorts depending on mode) which are to
  358.          be placed in contiguous locations of the bitplane.
  359.  
  360.          If there are no changed words in a given plane, then the pointer
  361.          in the first 32 bytes of the chunk is =0.
  362.  
  363.       2.2.2 Format for method 4
  364.  
  365.          The DLTA chunk is modified slightly to have 16 long pointers at
  366.          the start.  The first 8 are as before - pointers to the start of
  367.          the data for each of the bitplanes (up to a theoretical max of 8
  368.          planes).  The next 8 are pointers to the start of the offset/numbers
  369.          data list.  If there is only one list of offset/numbers for all
  370.          planes, then the pointer to that list is repeated in all positions
  371.          so the playback code need not even be aware of it.  In fact, one
  372.          could get fancy and have some bitplanes share lists while others
  373.          have different lists, or no lists (the problems in these schemes
  374.          lie in the generation, not in the playback).
  375.  
  376.          The best way to show the use of this format is in a sample playback
  377.          routine.
  378.  
  379.             SetDLTAshort(bm,deltaword)
  380.             struct BitMap *bm;
  381.             WORD *deltaword;
  382.             {
  383.                int i;
  384.                LONG *deltadata;
  385.                WORD *ptr,*planeptr;
  386.                register int s,size,nw;
  387.                register WORD *data,*dest;
  388.  
  389.                deltadata = (LONG *)deltaword;
  390.                nw = bm->BytesPerRow >>1;
  391.  
  392.                for (i=0;i<bm->Depth;i++) {
  393.                   planeptr = (WORD *)(bm->Planes[i]);
  394.                   data = deltaword + deltadata[i];
  395.                   ptr  = deltaword + deltadata[i+8];
  396.                   while (*ptr != 0xFFFF) {
  397.                      dest = planeptr + *ptr++;
  398.                      size = *ptr++;
  399.                      if (size < 0) {
  400.                         for (s=size;s<0;s++) {
  401.                            *dest = *data;
  402.                            dest += nw;
  403.                         }
  404.                         data++;
  405.                      }
  406.                      else {
  407.                         for (s=0;s<size;s++) {
  408.                            *dest = *data++;
  409.                            dest += nw;
  410.                         }
  411.                      }
  412.                   }
  413.                }
  414.                return(0);
  415.             }
  416.  
  417.          The above routine is for short word vertical compression with
  418.          run length compression.  The most efficient way to support
  419.          the various options is to replicate this routine and make
  420.          alterations for, say, long word or XOR.  The variable nw
  421.          indicates the number of words to skip to go down the vertical
  422.          column.  This one routine could easily handle horizontal
  423.          compression by simply setting nw=1.  For ultimate playback
  424.          speed, the core, at least, of this routine should be coded in
  425.          assembly language.
  426.  
  427.       2.2.2 Format for method 5
  428.  
  429.          In this method the same 16 pointers are used as in option 4.
  430.          The first 8 are pointers to the data for up to 8 planes.
  431.          The second set of 8 are not used but were retained for several
  432.          reasons.  First to be somewhat compatible with code for option
  433.          4 (although this has not proven to be of any benefit) and
  434.          second, to allow extending the format for more bitplanes (code
  435.          has been written for up to 12 planes).
  436.  
  437.          Compression/decompression is performed on a plane-by-plane basis.
  438.          For each plane, compression can be handled by the skip.c code
  439.          (provided Public Domain by Jim Kent) and decompression can be
  440.          handled by unvscomp.asm (also provided Public Domain by Jim Kent).
  441.  
  442.          Compression/decompression is performed on a plane-by-plane basis.
  443.          The following description of the method is taken directly from
  444.          Jim Kent's code with minor re-wording.  Please refer to Jim's
  445.          code (skip.c and unvscomp.asm) for more details:
  446.  
  447.             Each column of the bitplane is compressed separately.
  448.             A 320x200 bitplane would have 40 columns of 200 bytes each.
  449.             Each column starts with an op-count followed by a number
  450.             of ops.  If the op-count is zero, that's ok, it just means
  451.             there's no change in this column from the last frame.
  452.             The ops are of three classes, and followed by a varying
  453.             amount of data depending on which class:
  454.               1. Skip ops - this is a byte with the hi bit clear that
  455.                  says how many rows to move the "dest" pointer forward,
  456.                  ie to skip. It is non-zero.
  457.               2. Uniq ops - this is a byte with the hi bit set.  The hi
  458.                  bit is masked down and the remainder is a count of the
  459.                  number of bytes of data to copy literally.  It's of
  460.                  course followed by the data to copy.
  461.               3. Same ops - this is a 0 byte followed by a count byte,
  462.                  followed by a byte value to repeat count times.
  463.             Do bear in mind that the data is compressed vertically rather
  464.             than horizontally, so to get to the next byte in the destination
  465.             we add the number of bytes per row instead of one!
  466.  
  467.  
  468. -------------------------------------------------------------------------
  469. Appendix for Anim7 Formats               Wolfgang Hofer,      23.6.92
  470. -------------------------------------------------------------------------
  471.  
  472.  
  473.  
  474.    Anim method 7 is designed for maximum playback speed and acceptable
  475.    packing rates (packing usually not as good as method 5, but more
  476.    efficient than methodes 1 -- 4)
  477.  
  478.    Method 7 is not in the IFF specification today
  479.    but supported by the Public Domain Programs AAP/AAC.
  480.  
  481.  
  482.    #.# Chunk Sequence:
  483.  
  484.    Method 7 Anims should use the same Chunk Sequence as methods 1..5.
  485.    Alternativley the first frame may have a DLTA chunk instead
  486.    of the BODY chunk.
  487.    In that case the DLTA is the difference to a 'black frame'.
  488.    A player has to clear all bitplanes of the first bitmap to zero,
  489.    and then call his DLTA unpack routines for this frame.
  490.  
  491.               FORM ANIM
  492.               . FORM ILBM         first frame
  493.               . . BMHD                normal type IFF data
  494.               . . ANHD                optional animation header
  495.                           chunk for timing of 1st frame.
  496.               . . CMAP
  497.               . . { BODY |            full picture or
  498.                 DLTA }            difference to 'black frame'
  499.               . FORM ILBM         frame 2
  500.               . . ANHD                animation header chunk
  501.               . . DLTA                delta mode data
  502.               . . [CMAP]
  503.               . FORM ILBM         frame 3
  504.               . . ANHD
  505.               . . DLTA
  506.               . . [CMAP]
  507.                ...
  508.  
  509.       The initial FORM ILBM can contain all the normal ILBM chunks,
  510.       such as CRNG, etc.  The BODY will normally be a standard
  511.       run-length-encoded data chunk (but may be any other legal
  512.       compression mode as indicated by the BMHD).  If desired, an ANHD
  513.       chunk can appear here to provide timing data for the first
  514.       frame.  If it is here, the operation field should be =0.
  515.  
  516.       If the initial FORM ILBM uses a DLTA chunk, the ANHD chunk
  517.       must appear, and the operation field must be set to the
  518.       according anim method.
  519.  
  520.    # Chunk Formats
  521.    #.# ANHD Chunk for method 7
  522.       The ANHD chunk consists of the following data structure:
  523.  
  524.        UBYTE operation  The compression method:
  525.                 =7 short/long Vertical Delta mode
  526.  
  527.        UBYTE mask         unused
  528.        UWORD w,h          unused
  529.        WORD  x,y          unused
  530.        ULONG abstime      unused
  531.        ULONG reltime     (timing for frame relative to time
  532.                   previous frame was displayed - in
  533.                   jiffies (1/60 sec))
  534.        UBYTE interleave = 0 (see ANHD description above)
  535.        UBYTE pad0         unused
  536.        ULONG bits         32 option bits used by methode=4 and 5.
  537.                   methode 7 uses only bit #0
  538.  
  539.                  bit #              set =0               set =1
  540.                  ===============================================
  541.                  0              short data           long data
  542.  
  543.        UBYTE pad[16]       unused
  544.  
  545.  
  546.    #.# DLTA Chunk
  547.       #.#.# Format for method 7
  548.  
  549.      The DLTA Chunks of method7 consists of
  550.  
  551.      - 8 pointers    to opcode lists
  552.      - 8 pointers    to data lists
  553.      - data lists    (long/short)
  554.      - opcode lists  (bytes)
  555.  
  556.      In this method the DLTA Chunk begins with 16 pointers.
  557.      The first 8 longwords are pointers to the
  558.      opcode lists for up to 8 planes.
  559.      The second set of 8 longwords are pointers to the correspondig
  560.      data lists.
  561.      If there are less than 8 Planes all unused pointers are set to
  562.      zero.
  563.  
  564.      Compression/decompression is performed on a plane-by-plane basis.
  565.      The following description of the method is similar to
  566.      Jim Kent's methode 5, except that data is stored in a seperated
  567.      datalist (long or short, depending on bit#0 of the ANHD bits)
  568.      and doesn't follow immediate after the opcode.
  569.  
  570.      In methode 7 the bitplane is splitted into vertical columns.
  571.      Each column of the bitplane is compressed separately.
  572.      A 320x200 bitplane would have 20 columns of 200 short datas each.
  573.      (or 10 columns of 200 long datas)
  574.  
  575.      Each column starts with an op-count followed by a number
  576.      of ops.  If the op-count is zero, that's ok, it just means
  577.      there's no change in this column from the last frame.
  578.      The ops are of three classes. The ops refer to a varying
  579.      amount of data (to fetch from the corresponding datalist)
  580.      depending on which class:
  581.  
  582.           1. Skip ops - this is a byte with the hi bit clear that
  583.          says how many rows to move the "dest" pointer forward,
  584.          ie to skip. It is non-zero.
  585.          Skip ops have no corresponding data-items in the datalist.
  586.           2. Uniq ops - this is a byte with the hi bit set.  The hi
  587.          bit is masked down and the remainder is a count of the
  588.          number of data to copy literally from the datalist
  589.          to the "dest" pointer column. (Each data item to the
  590.          next destination row)
  591.          Data items may be long or short organized.
  592.           3. Same ops - this is a 0 byte followed by a count byte.
  593.          The count byte says how many rows of the current column
  594.          are to be set to the same data-item.
  595.          the data-item (long or short) is fetched from the
  596.          datalist.
  597.  
  598.         Do bear in mind that the data is compressed vertically rather
  599.         than horizontally, so to get to the next address in the
  600.         destination we have to add the number of bytes per row
  601.         instead of 2 (or 4)!
  602.